home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14311 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  10.1 KB
  1. Path: news.uh.edu!cosc19z5
  2. From: cosc19z5@Bayou.UH.EDU (Spasmo)
  3. Newsgroups: comp.lang.c,comp.unix.programmer
  4. Subject: Re: Q: '\n' character
  5. Followup-To: comp.lang.c,comp.unix.programmer
  6. Date: 13 Apr 1996 08:55:02 GMT
  7. Organization: University of Houston
  8. Message-ID: <4knq56$789@masala.cc.uh.edu>
  9. References: <4kj66f$k0o@ren.cei.net> <4kko80$8np@news.ld.centuryinter.net> <4kkvvsINN8fs@keats.ugrad.cs.ubc.ca> <4kmdsv$ojc@masala.cc.uh.edu> <4kmhpsINN7ak@keats.ugrad.cs.ubc.ca>
  10. NNTP-Posting-Host: bayou.uh.edu
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
  14. : In article <4kmdsv$ojc@masala.cc.uh.edu>, Spasmo <cosc19z5@Bayou.UH.EDU> wrote:
  15. :  >Actually from where I'm standing this is the comp.unix.programmer newsgroup.
  16. :  >Don't you love crossposting?  It also means that the response was in fact on
  17. :  >topic for us, but apparently not for you--the price of crossposting.
  18.  
  19. : Oops, I didn't notice that.
  20.  
  21. Well you should have.  Or do you just blindly post articles without
  22. even looking at where they are going?  Maybe this will be a lesson
  23. to you to actually pay attention to what you are doing.
  24.  
  25.  
  26. [Snip]
  27.  
  28. :  >The strlen() response was right, however it had the possibility of producing
  29. :  >undesired effects under certain conditions.  The user wanted a way to remove
  30.  
  31. : So how is it right if it had undesired effects under certain conditions?
  32.  
  33. The same way a myriad of other algorithms and solutions are right even
  34. though they may provide little or no error checking.  If a person
  35. asked about allocating memory, a dozen people would respond "malloc"
  36. and provide sample code, which might not check the return.  Does that
  37. make the sample code any less valid?  No.  It's a solution but error
  38. checking has been left out for brevity.
  39.  
  40.  
  41. :  >newlines, and the response above did it.  Of course in the case of a overly
  42.  
  43. : It did not. It removed the last character of the buffer.
  44.  
  45. Which is usually the newline.  Read up on fgets, it's obvious you don't
  46. know what it does.  
  47.  
  48.  
  49. :  >long line, the response would remove a valid character--however the fact
  50.  
  51. : And of course, *real* UNIX users don't put lines longer than 79 chars into a
  52. : textfile anyway...
  53.  
  54. Do you think you could actually say something without dripping sarcasm
  55. and animosity all over the place?  If you are interesting in discussing
  56. this matter, then try to behave maturely and try to keep this on a civil
  57. level.
  58.  
  59.  
  60. :  >remains that it does remove the newline, and with the addition of some minor
  61. :  >code can be made much safer--yet no one has shown the boundary conditions
  62. :  >because it's obvious that they can exist, and they are easy to accomodate.
  63.  
  64. : If they are easy to accomodate, why not write it properly in the first place?
  65.  
  66. Because it's *EASY TO ACCOMODATE*.  In the case where a complex test would
  67. be required I'd add it in, however this was simple enough that I saw no
  68. reason to add in extra code.
  69.  
  70.  
  71. : Humor me as to why it is necessary to retain a whole string of data just to
  72. : then scan through it to find its length to remove the trailining newline, which
  73. : was put there by a standard library function that already scanned the
  74. : characters once to _find_ the newline in the first place.
  75.  
  76.  
  77. That question should be asked of the person who wanted the help.  I
  78. responded to his request for newline stripping *PERIOD*.  He did not
  79. ask for an analysis of his design.
  80.  
  81.  
  82. :  >Also given the application, the conditions that would make the strlen()
  83. :  >solution unsafe may not even occur.
  84.  
  85. : Is this representative of your general attitude toward software design, or do
  86. : you properly reserve it for writing trivial half-a-pagers?
  87.  
  88. Do you know the exact details of his application?  No.  Do you know the
  89. nature (precise nature, not just "text file"), of the file he's trying
  90. to process?  No.  It's possible the file was produced by some process
  91. where lines are of a guaranteed length, and he's got a buffer large enough
  92. to accomodate them, newline included.  Of course it's possible that this
  93. isn't the case.  My point is we don't have the kind of intimate details
  94. available about his environment and the circumstances of his program
  95. to make any assumptions.  Hence we make none.
  96.  
  97.  
  98. :  >  So, the details of making the solution
  99. :  >more robust are left out.
  100.  
  101. : s/more robust/correct/
  102.  
  103. : A robust program is one that deals gracefully with bad input, not one that
  104. : manages to avoid failure with valid input. A robust program that doesn't want
  105. : to deal with long lines will define these as invalid input, and then somehow
  106. : handle their occurence.
  107.  
  108. *Yawn*.  So can you give us a definition of "gracefully", or is this just
  109. another one of your catch phrases that you so enjoy throwing around?
  110.  
  111.  
  112. :  > Perhaps this is an unwarranted assumption, however
  113. :  >it was an assumption that was made--at least in my case.  I was one of the
  114. :  >folks who suggested the strlen() solution as I use it when needed (with
  115. :  >proper checks of course).  And in case you haven't noticed, the strlen() fix
  116. :  >is directed at newline stripping which *IS* the right question.  Go back
  117. :  >and re-read the original post.
  118.  
  119. : Better yet, why don't I repost it?
  120.  
  121. : Hello everybody,
  122. :     Is there a function or some sort of way that I could remove '\n' 
  123. : charecter form the end of the string. I'm reading from two files, want to 
  124. : form one line of text and then have it printed out to stdout. I use fgets to 
  125. : read from the file and I noticed that it appends newline char at the end.
  126. :     It is important that two lines of text, one from each file, will be 
  127. : combined into one and I can't do it because the first string has '\n' added 
  128. : to it. I'm picky becauuse the output will be used to feed another program and 
  129. : I'm affraid that not properly formatted input may corrupt the process.
  130. :     Any suggestions will be greatly appreciated .. Thanks, Art ...
  131.  
  132. : Tell me again how I answered the wrong problem with my solution, and how you
  133. : answered the right one with your non-solution?
  134.  
  135. He asked about newlines.  You told him to rewrite his program.  I answered
  136. on how to strip newlines.  Therefore you are wrong and I am right.
  137.  
  138.  
  139. :  >And yes there are better solutions to the problem.  I like the strchr solution
  140. :  >posted by a few folks and will probably use that in preference to 
  141. :  >strlen(), however it does not take away from the validity of the original
  142.  
  143. : Ah yes. And then there is that fellow who insists that he has never seen a UNIX
  144. : system in which it was impossible to do *strchr(string, '\n') = '\0' regardless
  145. : of whether there actually is a '\n' character inside ``string''. Simply
  146. : brilliant!
  147.  
  148.  
  149. Kindly refrain from insulting others.  In case you haven't noticed, you
  150. are looking like quite an ass already so you shouldn't be commenting
  151. on the "brilliance" of others.
  152.  
  153.  
  154.  
  155. :  >And using UNIX commands to achieve what you need instead of C is far
  156. :  >more elegant, far less typing, far more robust, and far easier than
  157. :  >any code you can write.  Get a grip the guy above is discussing using
  158.  
  159. : I agree, but sadly, I had not noticed this was crossposted to a UNIX
  160. : newsgroup.
  161.  
  162.  
  163. Ordinarily a forgivable mistake, but given your attitude I can't let
  164. this pass.  You can't even tell where an article is getting crossposted
  165. and you criticize others?  You expect others to listen to you?  Pardon
  166. me while I laugh.
  167.  
  168.  
  169. :  >UNIX utilities instead of re-inventing the wheel.  And he's got a very
  170.  
  171. : Right, but in comp.lang.c, not everyone is a UNIX user. 
  172.  
  173. Crossposting again.  This thread has a bit of both so...
  174.  
  175.  
  176. :  >valid point.  With all the beautiful tools available under UNIX we can
  177. :  >get a lot done without having to write any code.  As it stands people
  178. :  >jump into a compiler to fix problems that can be better fixed without
  179. :  >writing software.  He has a very valid point.  You'd do well to stop
  180. :  >babbling and start listening.
  181.  
  182. : I know my UNIX tools well, but I'm not going to push the beautiful beasties
  183. : onto Mac, OS/2, Windows or VMS programmers that may be reading comp.lang.c. I
  184. : do use UNIX and advocate it and its tools elsewhere, like comp.os.*.advocacy.
  185.  
  186. Tsk tsk tsk, what did we just agree upon?  This is a crossposted article.
  187.  
  188.  
  189.  
  190. : Other than that I can _babble_ all I want---I earn that right by posting
  191. : correct answers that are tested to work, and get the poor newbie on the right
  192. : track, which is what these two newsgroups are for. I never flamed the one who
  193. : started this thread with a honest programming question, just the incorrect,
  194. : useless help he was getting which is worse than no help at all.
  195.  
  196. You have earned nothing.  Everyone on a newsgroup should practice a degree
  197. of etiquette.  I don't care if you answered a billion questions in your
  198. life, that doesn't give you the right to insult.  And as for posting
  199. good answers, you have yet to do that!
  200.  
  201.  
  202. : Why should I _listen_ to you? You can't even post a solution to a trivial
  203. : problem without overcomplicating it and buggering it up.  
  204.  
  205. And why should anyone listen to you?  You can't even read a simple article
  206. properly!  A user asks about stripping newlines and you tell him to rewrite
  207. his program.  Then you have the audacity to insult the others who unlike
  208. you actually *ANSWERED* his questions.  Had you even had a semblence of
  209. decency about the whole thing, your whole idiotic rant might have been
  210. tolerable, but you couldn't even do that!
  211.  
  212.  
  213. I find it utterly humorous that I post a line of code without error
  214. checking and I'm accused of overcomplicating and buggering up by a guy
  215. who tells the poster to re-write the whole thing! 
  216.  
  217. : -- 
  218.  
  219.  
  220. --
  221.  
  222.                       .A.                        G-Force!  1 AM Houston Time
  223.                      AAAAA                       On the Cartoon Network!
  224.                     AAY:YAA   
  225.                     A':::`A                      This informative message was 
  226.                     :::::::                      brought to you by Spasmo.
  227.                     ::( )::   
  228.                     :::::::
  229.                     :::::::
  230.                     :::::::
  231.                     :::::::     
  232.   .A.          .do:::::::::::bo.          .A.
  233.   AAA       .:::::::::::::::::::::.       AAA
  234.  d:::::::::::::::::::::::::::::::::::::::::::b
  235.  Y:::::::::::::::::::::::::::::::::::::::::::Y 
  236.  `YjY       `:::::::|::|::|:::::::'       YjY' 
  237.                  `::|::|::|::'  
  238.                        |
  239.